Generične medicinske naprave in tipa varnost: Nevidni temelj globalne zdravstvene tehnologije

Predstavljajte si medicinsko sestro v prometni enoti intenzivne nege. Monitor pacienta, ki ga je izdelalo nemško podjetje, je povezan z infuzijsko črpalko japonskega proizvajalca, ki nato pošilja podatke centralnemu sistemu za upravljanje podatkov o pacientu (PDMS), razvitemu v ZDA. V teoriji je to obljuba sodobnega, modularnega zdravstva: prožen, stroškovno učinkovit ekosistem naprav, ki delujejo v sozvočju. Kaj pa se zgodi, ko črpalka, programirana za poročanje o odmerku '10,5' mL/h, te podatke pošlje kot niz besedila, PDMS, ki pričakuje čisto število, pa bodisi odpove bodisi ga zaokroži navzdol na celo število '10'? Posledice te na videz majhne neskladnosti podatkov so lahko katastrofalne. To je kritičen, pogosto spregledan izziv tipa varnosti v svetu generičnih in interoperabilnih medicinskih naprav.

Ko se zdravstvena tehnologija oddaljuje od monolitnih, enovendorskih sistemov proti povezanemu internetu medicinskih stvari (IoMT), sta koncepta "generičnih" naprav in programske interoperabilnosti postala najpomembnejša. Vendar pa ta napredek uvaja novo plast kompleksnosti in tveganja. Prav tiste povezave, ki obljubljajo večjo učinkovitost in boljše rezultate za paciente, se lahko, če jih ne upravljamo z izjemno skrbnostjo, spremenijo v vektorje napak. V središču tega izziva leži tipa varnost – temeljni koncept računalništva, ki ima v kliničnem okolju posledice življenja ali smrti. Ta objava se bo poglobila v stičišče generičnih medicinskih naprav in tipa varnosti, raziskovala tveganja, globalni regulativni okvir in najboljše prakse, ki jih morajo proizvajalci, zdravstvene organizacije in klinični zdravniki sprejeti za izgradnjo varnejše, resnično povezane zdravstvene prihodnosti.

Razumevanje "Generičnega" v Kontekstu Medicinskih Naprav

Ko slišimo besedo "generični", pogosto pomislimo na neblagovne farmacevtske izdelke – kemično identično, a cenejše nadomestilo za blagovno znamko zdravila. V svetu medicinskih naprav ima izraz "generični" drugačen, bolj niansiran pomen. Gre manj za blagovno znamko in bolj za standardizacijo, modularnost in funkcionalno enakovrednost.

Onkraj blagovnih znamk: Kaj opredeljuje "generični" sestavni del?

Generična medicinska naprava ali sestavni del je tista, ki je zasnovana za opravljanje standardne funkcije in vmesnik z drugimi sistemi, ne glede na prvotnega proizvajalca. Gre za razdelitev kompleksnih medicinskih sistemov na zamenljive dele. Razmislite o teh primerih:

• Standardizirani priključki: Priključek Luer-Lok je klasičen primer. Omogoča varno povezavo brizg, IV cevk in katetrov neštetih proizvajalcev, kar ustvarja univerzalni standard.
• Modularni monitorji za paciente: Sodoben sistem za spremljanje pacientov je lahko opremljen z osrednjo prikazovalno enoto z režami za različne module (EKG, SpO2, NIBP, temperatura). Bolnišnica lahko kupi modul SpO2 od prodajalca A in modul EKG od prodajalca B ter ju priključi v centralno postajo prodajalca C, pod pogojem, da vsi upoštevajo enake fizične standarde in standarde za izmenjavo podatkov.
• Programski sestavni deli: Generični algoritem za zaznavanje aritmij v EKG valu bi se lahko licenciral in integriral v EKG naprave več različnih proizvajalcev.
• Komunikacijski protokoli: Naprave, ki "govorijo" standardizirane jezike, kot sta HL7 (Health Level Seven) ali FHIR (Fast Healthcare Interoperability Resources), se lahko štejejo za generične v svoji zmožnosti komunikacije, kar omogoča njihovo integracijo v širši informacijski sistem bolnišnice.

Gonilna sila tega trenda je prizadevanje za bolj prožen, konkurenčen in inovativen zdravstveni ekosistem. Bolnišnice želijo preprečiti "vendor lock-in", kar jim omogoča, da izberejo najboljšo napravo za vsako specifično potrebo, namesto da bi jih prisilili k nakupu vsega od enega samega, lastniškega dobavitelja.

Vzpon interoperabilnosti in interneta medicinskih stvari (IoMT)

Ta premik k generičnim sestavnim delom je temeljni načelo interneta medicinskih stvari (IoMT). IoMT si predstavlja mrežo povezanih naprav – od nosljivih senzorjev in pametnih infuzijskih črpalk do ventilatorjev in kirurških robotov – ki nenehno zbirajo, delijo in analizirajo podatke, da bi zagotovili celovit pogled na zdravje pacienta. Koristi so globoke:

• Izboljšano spremljanje pacientov: Podatki v realnem času iz več virov se lahko zberejo za zgodnje odkrivanje poslabšanja stanja pacienta.
• Izboljšani klinični delovni procesi: Avtomatizacija lahko zmanjša ročni vnos podatkov, zmanjša človeške napake in sprosti klinično osebje.
• Odpravljanje napak na podlagi podatkov: Obsežna analiza podatkov lahko vodi do boljših protokolov zdravljenja in napovednih diagnostik.
• Stroškovna učinkovitost: Konkurenca med proizvajalci komponent in možnost nadgradnje delov sistema namesto celotnega sistema lahko privede do znatnih prihrankov.

Vendar je ta povezanost dvorezni meč. Vsaka povezovalna točka, vsaka izmenjava podatkov med napravami različnih proizvajalcev, je potencialna točka napake. Predpostavka, da bosta dve napravi "delovali skupaj", ker si delita skupni vtič ali protokol, je nevarna poenostavitev. Tu se abstraktni svet inženirstva programske opreme in tipa varnosti sreča s fizično realnostjo oskrbe pacientov.

Tipa Varnost: Koncept Računalništva z Posledicami Življenja ali Smrti

Da bi resnično razumeli tveganja v našem povezanem medicinskem svetu, moramo razumeti temeljno načelo razvoja programske opreme: tipa varnost. Za mnoge zdravstvene delavce se to morda zdi kot ezoteričen IT izraz, vendar so njegove posledice izjemno praktične in neposredno povezane z varnostjo pacientov.

Kaj je Tipa Varnost? Osnove za Zdravstvene Delavce

V najpreprostejši obliki je tipa varnost sposobnost programskega jezika ali sistema, da prepreči napake, ki nastanejo zaradi mešanja nezdružljivih vrst podatkov. "Vrsta podatkov" je le način razvrščanja informacij. Pogosti primeri vključujejo:

• Cela števila: Polno število (npr. 10, -5, 150).
• Števila s plavajočo vejico (Float): Število z decimalno piko (npr. 37,5, 98,6, 0,5).
• Niz: Zaporedje znakov besedila (npr. "Ime pacienta", "Dajanje zdravila", "10,5 mg").
• Boolean: Vrednost, ki je lahko le resnična ali neresnična.

Pomislite na to kot na enote v medicini. Ne morete seštevati 5 miligramov in 10 litrov, da bi dobili smiseln rezultat. Enote ( "vrste") so nezdružljive. V programski opremi lahko poskus izvajanja matematične operacije na besedilnem nizu ali podajanje decimalne vrednosti funkciji, ki sprejema samo cela števila, povzroči nepredvidljivo vedenje. Tipno varen sistem je zasnovan tako, da te neskladnosti zazna in prepreči njihovo škodo.

Kritičen medicinski primer: Infuzijska črpalka mora dostaviti odmerek 12,5 mg/h. Programska funkcija, ki upravlja motor, pričakuje to vrednost kot število s plavajočo vejico. Povezan sistem elektronskega zdravstvenega zapisa (EHR), zaradi lokalizacijske napake (npr. uporaba vejice kot decimalnega ločila v Evropi), pošlje vrednost kot besedilni niz "12,5".

• V tipno nevarnem sistemu: Sistem bi morda poskusil "pretvori" niz v število. Morda bi videl vejico in skrajšal niz, ga interpretiral kot celo število '12'. Pacient bi prejel odmerek 12 mg/h namesto 12,5 mg/h. V drugih primerih bi lahko popolnoma zrušil programsko opremo črpalke, ustavil infuzijo brez alarma.
• V tipno varnem sistemu: Sistem bi takoj prepoznal, da niz ("12,5") ni enake vrste kot pričakovano število s plavajočo vejico. Zavrnil bi neveljavne podatke in sprožil poseben, visoko prioritativni alarm, ki bi kliničnega zdravnika opozoril na napako neskladnosti podatkov, preden bi prišlo do škode.

Statično in dinamično tipiziranje: Preprečevanje proti zaznavanju

Brez pretiranega tehničnega poglabljanja je koristno vedeti, da obstajata dva glavna pristopa k zagotavljanju tipa varnosti:

1. Statično tipiziranje: Preverjanja tipov se izvajajo med razvojno (kompilacijsko) fazo, še preden se programska oprema kdaj zažene. To je kot farmacevt, ki preveri recept za pravilnost, preden je sploh izpolnjen. To je preventivni pristop in je na splošno velja za varnejšega za misijonsko kritične sisteme, kot je vgrajena programska oprema medicinskih naprav, saj že na začetku odpravi celotne razrede napak. Jeziki, kot so C++, Rust in Ada, so statično tipizirani.
2. Dinamično tipiziranje: Preverjanja tipov se izvajajo med izvajanjem programa (ob izvajanju). To je kot medicinska sestra, ki natančno preveri zdravilo in odmerek ob postelji pacienta tik pred dajanjem. Ponuja večjo prožnost, vendar nosi tveganje, da se tipna napaka odkrije le v določeni, redki situaciji, morda dolgo po namestitvi naprave. Jeziki, kot sta Python in JavaScript, so dinamično tipizirani.

Medicinske naprave pogosto uporabljajo kombinacijo obeh. Glavne funkcije, ki rešujejo življenja, so običajno zgrajene s statično tipiziranimi jeziki za največjo varnost, medtem ko se lahko manj kritični uporabniški vmesniki ali nadzorne plošče za analizo podatkov uporabljajo dinamično tipizirane jezike za hitrejši razvoj in prožnost.

Stičišče: Kje se Generične Naprave Srečajo s Tveganji Tipa Varnosti

Osrednja teza te razprave je, da je prav ta interoperabilnost, ki naredi generične naprave tako privlačne, tudi njihov največji vir tveganj, povezanih s tipi. Ko en proizvajalec nadzoruje celoten sistem (črpalko, monitor in centralno programsko opremo), lahko zagotovi doslednost vrst podatkov v svojem ekosistemu. Toda v okolju z več prodajalci te garancije izginejo.

Scenarij "Plug and Pray": Nočne More Interoperabilnosti

Oglejmo si ponovno naš mednarodni scenarij na oddelku za intenzivno nego. Bolnišnica priključi novo napravo na svoje obstoječe omrežje. Kaj se lahko pokvari na ravni podatkov?

• Neskladnost enot: Tehtnica iz ZDA pošlje težo pacienta v funtih (lbs). Povezan program za izračun odmerka, razvit v Evropi, pričakuje kilograme (kg). Brez izrecnega polja za enote in sistema, ki ga preverja, program morda obravnava '150' lbs kot '150' kg, kar vodi do potencialno smrtnega prevelikega odmerka. To ni strogo tipna napaka (obe sta števili), vendar je to tesno povezana semantična napaka, pri kateri lahko robustni tipni sistemi pomagajo tako, da zahtevajo, da se podatki združijo z njihovo tipsko enoto.
• Neskladnost formatov podatkov: Naprava v ZDA zabeleži datum kot MM/DD/YYYY (npr. 10. 4. 2023 za 10. april). Evropski sistem pričakuje DD/MM/YYYY. Ko prejme '04/10/2023', ga interpretira kot 4. oktober, kar vodi do napačnih zapisov pacientov, napak pri časovni razporeditvi zdravil in napačnih analiz trendov.
• Implicitna pretvorba vrst: To je ena najbolj zahrbtnih napak. Sistem, ki se trudi biti "koristen", samodejno pretvori podatke iz ene vrste v drugo. Na primer, merilnik krvnega sladkorja poroča o vrednosti "85,0". Prejemni sistem potrebuje celo število, zato izpusti decimalno piko in shrani '85'. To se zdi v redu. Kaj pa, če merilnik sporoči "85,7"? Sistem ga morda skrajša na '85', izgubi natančnost. Drugačen sistem ga morda zaokroži na '86'. Ta nedoslednost ima lahko resne klinične posledice, zlasti ko se podatki zbirajo skozi čas.
• Obravnavanje ničnih ali nepričakovanih vrednosti: Senzor krvnega tlaka začasno odpove in namesto števila pošlje vrednost `null` (kar pomeni 'brez podatkov'). Kako se odzove centralni sistem za spremljanje? Ali sproži alarm? Ali prikaže '0'? Ali preprosto prikaže zadnjo veljavno odčitano vrednost, kar kliničnega zdravnika zavede v prepričanje, da je pacient stabilen? Robustna, tipno varna zasnova predvideva te robne primere in za vsakega definira varen, izrecen način delovanja.

Izziv komunikacijskih protokolov: HL7, FHIR in semantična vrzel

Morda bi kdo predpostavil, da standardizirani protokoli, kot sta HL7 in FHIR, rešujejo te težave. Čeprav so velik korak v pravo smer, niso čarobna rešitev. Ti protokoli definirajo strukturo in sintakso za izmenjavo zdravstvenih informacij – "gramatiko" pogovora. Vendar pa ne vedno strogo prisilijo "pomena" (semantike) ali specifičnih vrst podatkov znotraj te strukture.

Na primer, FHIR vir za "Opazovanje" ima lahko polje z imenom `valueQuantity`. FHIR standard določa, da mora to polje vsebovati numerično vrednost in enoto. Nepravilno implementirana naprava pa lahko v polje za opombe namesto ustrezne kode v polju vrednosti umesti besedilni niz "Previsoko za merjenje". Nepravilno zasnovan sprejemni sistem morda ne ve, kako ravnati s to odstopanjem od norme, kar vodi do izgube podatkov ali nestabilnosti sistema.

To je "semantični interoperabilnosti" izziv: dva sistema lahko uspešno izmenjata sporočilo, vendar njegov pomen lahko interpretirata različno. prava tipa varnost na sistemski ravni vključuje ne le preverjanje strukture podatkov, temveč tudi njihovo vsebino in kontekst.

Regulativni Okvir: Globalna Perspektiva Varnosti Programske Opreme

Regulatorna telesa po vsem svetu so ob prepoznavanju teh tveganj vse bolj poudarjala validacijo programske opreme, obvladovanje tveganj in interoperabilnost. Globalni proizvajalec se ne more osredotočiti na predpise ene države; mora krmariti po zapletenem omrežju mednarodnih standardov.

Ključna regulatorna telesa in njihov odnos

• Ameriška uprava za hrano in zdravila (FDA): FDA ima obsežne smernice za programsko opremo medicinskih naprav, vključno s "Programsko opremo kot medicinsko napravo" (SaMD). Poudarjajo pristop, ki temelji na tveganju, in od proizvajalcev zahtevajo predložitev podrobnih dokumentov o njihovi zasnovi programske opreme, validaciji in procesih preverjanja. Njihov poudarek na kibernetski varnosti je prav tako zelo pomemben, saj številne varnostne ranljivosti izhajajo iz slabega obravnavanja nepričakovanih vnosov podatkov – težave, ki je tesno povezana s tipa varnostjo.
• Uredba EU o medicinskih pripomočkih (EU MDR): EU MDR, ki je nadomestila prejšnjo Direktivo o medicinskih pripomočkih (MDD), močno poudarja celoten življenjski cikel izdelka, vključno z nadzorom po trženju. Od proizvajalcev zahteva zagotavljanje veliko strožjih kliničnih dokazov in tehnične dokumentacije. Za programsko opremo to pomeni dokazovanje, da je naprava varna in deluje, kot je predvideno, zlasti ko je povezana z drugimi napravami.
• Mednarodni forum regulatorjev medicinskih pripomočkov (IMDRF): To je prostovoljna skupina regulatorjev z vsega sveta (vključno z ZDA, EU, Kanado, Japonsko, Brazilijo in drugimi), ki si prizadeva za harmonizacijo regulativ za medicinske pripomočke. Njihove smernice o temah, kot je kategorizacija tveganja SaMD, vplivajo na postavitev globalne osnovne ravni pričakovanj glede varnosti in učinkovitosti.

Standardi na pomoč: ISO, IEC in AAMI

Za izpolnitev teh regulativnih zahtev proizvajalci uporabljajo vrsto mednarodnih standardov. Za programsko opremo je najpomembnejši IEC 62304.

• IEC 62304 – Medicinske naprave – Procesi življenjskega cikla programske opreme: To je zlati standard za razvoj programske opreme medicinskih naprav. Ne predpisuje, *kako* pisati kodo, ampak definira strog okvir za celoten proces: načrtovanje, analiza zahtev, arhitekturno oblikovanje, kodiranje, testiranje, izdaja in vzdrževanje. Upoštevanje IEC 62304 prisili razvojne ekipe, da od samega začetka razmišljajo o tveganjih, vključno s tveganji zaradi interoperabilnosti in neskladnosti podatkov.
• ISO 14971 – Uporaba obvladovanja tveganj za medicinske pripomočke: Ta standard zahteva od proizvajalcev, da identificirajo, analizirajo in obvladujejo tveganja, povezana z njihovimi napravami v celotnem življenjskem ciklu. Tipna neskladnost, ki povzroči napako pri odmerjanju, je klasična nevarnost, ki jo je treba identificirati v analizi tveganj. Proizvajalec mora nato implementirati ukrepe za zmanjšanje tveganja (kot je robustno preverjanje podatkov in tipov) ter dokazati, da ti ukrepi zmanjšajo tveganje na sprejemljivo raven.

Ti standardi nalagajo odgovornost neposredno proizvajalcu, da dokaže, da je njegova naprava varna, ne le sama po sebi, temveč v kontekstu predvidene uporabe – kar vedno pogosteje pomeni povezavo z drugimi sistemi.

Najboljše Prakse za Zagotavljanje Tipa Varnosti v Zdravstveni Tehnologiji

Zagotavljanje varnosti pacientov v povezanem svetu je deljena odgovornost. Zahteva skrbnost inženirjev, ki pišejo kodo, bolnišnic, ki implementirajo tehnologijo, in kliničnega osebja, ki jo uporablja ob postelji.

Za Proizvajalce Medicinskih Naprav

1. Sprejmite "Varnost na prvem mestu" Filozofijo Zasnove: Uporabljajte močno tipizirane programske jezike (npr. Rust, Ada, C++, Swift) za varnostno kritične komponente. Ti jeziki omogočajo napako ob kompilaciji pri mešanju nezdružljivih tipov, kar odpravi celotne kategorije napak, še preden se programska oprema sploh testira.
2. Prakticirajte Obrambno Programiranje: Vse podatke, ki prihajajo iz zunanje naprave ali sistema, obravnavajte kot potencialno zlonamerne ali napačno oblikovane, dokler niso validirani. Nikoli ne zaupajte prihajajočim podatkom. Pred obdelavo preverite tip, obseg, format in enote.
3. Implementirajte Strogo Testiranje: Pojdite dlje od "happy path" testiranja. Enotski in integracijski testi morajo vključevati robne primere: dovajanje napačnih vrst podatkov, vrednosti izven območja, nične vnose in napačno oblikovane nize na vsakem vmesniku, da zagotovite, da sistem varno odpove (torej s sprožitvijo alarma in zavrnitvijo podatkov).
4. Zagotovite kristalno čisto dokumentacijo: Dokumentacija vmesnika za programiranje aplikacij (API) za napravo mora biti nedoločena. Za vsako podatkovno točko, ki jo je mogoče izmenjati, mora izrecno navajati zahtevani tip podatkov, enote (npr. "kg", ne samo "teža"), pričakovani obseg in format (npr. ISO 8601 za datume).
5. Uporabite podatkovne sheme: Na vsakem elektronskem vmesniku uporabite formalno shemo (kot je JSON Schema ali XML Schema Definition) za programsko validacijo strukture in vrst podatkov prihajajočih informacij. To avtomatizira proces validacije.

Za Zdravstvene Organizacije in IT Oddelke

1. Razviti Celovito Integracijsko Strategijo: Ne dovolite ad hoc povezovanja naprav. Imeti morate formalno strategijo, ki vključuje temeljito oceno tveganja za vsako novo napravo, ki je dodana omrežju.
2. Zahtevajte izjave o skladnosti od prodajalcev: Med nabavo zahtevajte od prodajalcev, da predložijo podrobne izjave o skladnosti, ki določajo, katere protokole podpirajo in kako jih implementirajo. Zastavite ciljana vprašanja o tem, kako njihova naprava obravnava validacijo podatkov in pogoje napak.
3. Ustvarite "Sandbox" za Testiranje: Vzdržujte izolirano, neklinično omrežje ("sandbox") za testiranje novih naprav in posodobitev programske opreme. V tem "sandboxu" simulirajte celoten potek kliničnih podatkov od začetka do konca, da razkrijete interoperabilnostne težave, preden je naprava uporabljena s pacienti.
4. Vlagajte v "Middleware": Uporabite integracijske motorje ali "middleware" kot osrednje vozlišče za komunikacijo med napravami. Ti sistemi lahko delujejo kot "univerzalni prevajalec" in "varnostni prehod", ki validirajo, transformirajo in normalizirajo podatke iz različnih naprav, preden jih posredujejo EHR ali drugim kritičnim sistemom.
5. Spodbujajte kulturo sodelovanja: Klinični inženirski (biomedicinski) timi in IT oddelki morajo tesno sodelovati. Ljudje, ki razumejo klinične delovne procese, morajo sodelovati z ljudmi, ki razumejo podatkovne tokove, da bi identificirali in zmanjšali tveganja.

Za Klinične Zdravnike in Končne Uporabnike

1. Zagovarjajte Usposabljanje: Klinični zdravniki morajo biti usposobljeni ne le za uporabo naprave, temveč tudi za osnove njene povezljivosti. Morali bi razumeti, kateri podatki se pošiljajo in prejemajo, ter kaj pomenijo pogosta sporočila o napakah ali opozorila.
2. Bodite Pozorni in Poročajte o Anomalijah: Klinični zdravniki so zadnja obrambna linija. Če naprava prikaže nepričakovane podatke, če se številke ne zdijo pravilne ali če sistem po povezavi nove naprave deluje počasneje, je treba to takoj sporočiti tako kliničnemu inženirstvu kot IT-ju. Te povratne informacije po trženju so neprecenljive za odkrivanje subtilnih napak, ki so bile spregledane med testiranjem.

Prihodnost: AI, Strojno Učenje in Nova Meja Tipa Varnosti

Izzivi tipa varnosti se bodo z razvojem umetne inteligence (AI) in strojnega učenja (ML) v medicini le še povečevali. AI algoritem, zasnovan za napovedovanje sepse, je morda treniran na ogromnem naboru podatkov iz specifičnega niza pacientovih monitorjev. Kaj se zgodi, ko bolnišnica vanj vnese podatke z nove, drugačne znamke monitorja? Če novi monitor meri parameter v nekoliko drugačnih enotah ali ima drugačno raven natančnosti, bi to lahko subtilno izkrivilo vnos AI, kar bi povzročilo nevarno napačno diagnozo.

Narava "črne skrinjice" nekaterih kompleksnih ML modelov te težave še otežuje odpravljanje napak. Potrebujemo nove standarde in tehnike validacije, posebej zasnovane za medicinske naprave, ki temeljijo na AI, da zagotovimo, da delujejo robustno in predvidljivo, tudi ko se soočajo s podatki iz raznolikega in razvijajočega se ekosistema generičnih naprav.

Zaključek: Gradnja Varnejše, Povezane Zdravstvene Prihodnosti

Premik k modularnemu, interoperabilnemu zdravstvenemu ekosistemu, zgrajenemu na "generičnih" medicinskih napravah, ni le neizbežen, ampak tudi zaželen. Obljublja bolj inovativen, učinkovit in stroškovno učinkovit prihodnost za globalno zdravstvo. Vendar ta napredek ne sme biti na račun varnosti pacientov.

Tipa varnost ni le abstrazen problem za inženirje programske opreme; je nevidni temelj, na katerem je zgrajena zanesljiva in varna interoperabilnost medicinskih naprav. Neupoštevanje pomena vrst podatkov, enot in formatov lahko povzroči poškodbe podatkov, diagnostične napake in nepravilno dostavo zdravljenja. Zagotavljanje te varnosti je deljena odgovornost. Proizvajalci morajo načrtovati in graditi obrambno. Regulatorji morajo še naprej razvijati globalne standarde. Zdravstvene organizacije pa morajo te tehnologije implementirati in upravljati z rigorozno, na varnost osredotočeno metodologijo.

Z dajanjem prednosti robustni validaciji podatkov in spodbujanjem kulture sodelovanja lahko izkoristimo izjemno moč povezane tehnologije za izboljšanje rezultatov pacientov, z zaupanjem, da sistemi, ki jih gradimo, niso le pametni, ampak predvsem, varni.